Re: autovacuum daemon question...
От | Jeff Bohmer |
---|---|
Тема | Re: autovacuum daemon question... |
Дата | |
Msg-id | p06230900bf9961d37627@[192.168.1.200] обсуждение исходный текст |
Ответ на | Re: autovacuum daemon question... ("Matthew T. O'Connor" <matthew@zeut.net>) |
Ответы |
Re: autovacuum daemon question...
|
Список | pgsql-admin |
>>Unless I misunderstand, if stats_reset_on_server_start=off, these >>(currently nonexistent autovacuum) stats would only be relevant for >>autovacuum's VACUUM activity and not it's ANALYZE activity. In >>which case, it seems ideal to keep autovacuum VACUUM stats >>regardless of the GUC setting, while autovacuum ANALYZE stats >>should follow it. But if the ideal is impractical, making both >>ANALYZE and VACUUM stats follow the GUC would still be real nice. > >I'm confused... the GUC var stats_reset_on_server_start dictates if >the stats system dumps its data on DB restart. If we added a new >table to the stats system kept track of autovacuum activity, then >that data would also be dumped on restart if >stats_reset_on_server_start=true. Yep. I was thinking of a way to muck up the stats system by keeping autovacuum's VACUUM activity irregardless of stats_reset_on_server_start. Because autovacuum's VACUUM activity data would be relevant across restarts, even if stats_reset_on_server_start=true. But I see now that my idea is ugly and just confuses things. I agree that having it work the way you suggest is preferable. - Jeff -- Jeff Bohmer VisionLink, Inc.
В списке pgsql-admin по дате отправления: